introduce batch submission API#152
Conversation
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
| type BatchRequest struct { | ||
| Requests []*BaseRequest `json:"requests"` | ||
| } |
There was a problem hiding this comment.
The proposal uses a top-level requests attribute to group the requests instead of accepting an array of requests directly.
This makes the input payload extensible if we want to add batch options in the feature.
Same thinking on the response object.
|
Example input: Example output: Mixed failure and success: |
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
| deployReqs = append(deployReqs, &tReq) | ||
| deployIndices = append(deployIndices, i) | ||
|
|
||
| default: |
There was a problem hiding this comment.
I do think it's a little confusing that:
- We have a separate
/batchAPI ... - ... but we don't support batch submission of all the types (only
SendTransactionandDeployContract) - ... and we don't actually execute a parallel batch across those
Can you elaborate on the reason for not doing either of:
- Having two new payload types on the existing
/RPC-style payload likeDeployContractBatchandSendTransactionBatch - Just having a
Batchtype on/that supports any set of the existing types
There was a problem hiding this comment.
@peterbroadhurst that's a great question.
There are 3 design considerations:
Introduce new types in / vs introduce a /batch API.
The latter is my preferred pick because it does not further complicate the schema of the API, here is how the schema look like for / today, introduces a batch spelling inside it will be messy:

Why is the execution order of batch not cross-type?
For example, if the input is:
SendTransactionBatch 1,DeployContractBatch 2,SendTransactionBatch 3,SendTransactionBatch 4
Why the execution order is not 1, 2, 3, 4 but 1, 3, 4, 2 instead?
I think my implementation was influeced by how the existing code is structured. 1, 2, 3, 4 is actually the preferred order. Especially given that contract deployment can generate a deterministic address, so that putting contract deployment and its invocations in the same batch is valid.
I'll fix the code to use the correct order This will change the txHandler interface to have a generic batch API interface. Unlike the existing singular methods, which spell HandleNewTransaction and HandleNewContractDeployment as separate functions, other than a single generic function (e.g. HandleTransaction that's type aware.)
Why doesn't batch support query or receipt checking?
Because conveying the meaning of their orders is tricky.
Unlike the batching behaviour in Ethereum API (following JSON-RPC spec, in which the items are not guaranteed to be executed in the input order), the introduced /batch API uses the order of the input to calculate nonce (which enables order preserving despite the parallel execution if batch is used in JSON-RPC API).
Despite keeping the order for queries might not make a huge difference in the result, because transactions are processed asynchronously, it is still hard to explain the execution order differences.
There was a problem hiding this comment.
This is a great write-up. Thank you
I wonder given all of the complexity above, I personally feel:
- You've fully convinced me we should scope batches to things that can be ordered correctly in a batch-insert
- The user should decide the order, not us. They know their transactions, not us.
So actually this leads me to question - why do we want separate SendTransaction and DeployContract types at all?
Can we not:
- Make the batch payload to include the combined fields of
SendTransactionandDeployContract - Make all the entries in the batch the same - no
typeon the headers - Call the API
/batchsubmit
There was a problem hiding this comment.
The batch API does look different enough to endorse a more specific endpoint spelling to indicate it's submission only.
Will merge the types as suggested. The SendTransaction and DeployContract types probably can be combined in the singular API spelling as well.
…ger into batch-submission
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
Signed-off-by: Chengxuan Xing <chengxuan.xing@kaleido.io>
|
@peterbroadhurst thanks for the review comment. I've merged the 2 types into a single generic type and introduced a new |
peterbroadhurst
left a comment
There was a problem hiding this comment.
Thanks for working through the update to the spelling on this.
This PR introduces a new
/submitendpoint that allows clients to submit multiple transactions and contract deployment requests in a single HTTP call. This significantly improves throughput and reduces overhead for bulk operations.Users can now submit multiple
SendTransactionandDeployContractrequests in a single API call through a separate/submitAPI, which has default support for batch submissions.All valid transactions in a batch are persisted in a single database transaction (for transactions with the same signer).
API Usage
POST /submit
Response: